The present invention relates generally to electronic mail (e-mail) systems and, more particularly, to improved methodology to enforce authentication or encryption to/from Mail Transfer Agents and from Mail User Agents.
Today, electronic mail or “e-mail” is a pervasive, if not the most predominant, form of electronic communication. FIG. 1 illustrates the basic architecture of a typical electronic mail system 10. At a high level, the system includes a mail server connected over a network to various e-mail “clients,” that is, the individual users of the system. More specifically, the system 10 includes one or more clients 11 connected over a network to at least one SMTP (Simple Mail Transport Protocol) server or “Message Transfer Agent” (MTA) 12a for routing e-mail. Users write, send, and read e-mail via Mail User Agents (MUA), such as Microsoft Outlook™ or mutt, present at each client (computer). To send e-mail, an MUA connects to an MTA which receives the e-mail and routes it to another MTA. An intermediary MTA might forward the e-mail to yet another MTA until the e-mail reaches the destination system, where the e-mail is stored in a mailbox accessible by the recipient.
A typical e-mail delivery process is as follows. In the following scenario, Larry sends e-mail to Martha at her e-mail address: martha@example.org. Martha's Internet Service Provider (ISP) uses an MTA, such as provided by Sendmail® for NT, available from Sendmail, Inc. of Emeryville, Calif. (With a lower case “s,” “sendmail” refers to Sendmail's MTA, which is one component of the Sendmail® Switch product line.)    1. Larry composes the message and chooses Send in Microsoft Outlook Express (a “Mail User Agent” or MUA). The e-mail message itself specifies one or more intended recipients (i.e., destination e-mail addresses), a subject heading, and a message body; optionally, the message may specify accompanying attachments.    2. Microsoft Outlook Express queries a DNS server for the IP address of the local mail server running sendmail. The DNS server translates the domain name into an IP address, 10.1.1.1, of the local mail server.    3. Microsoft Outlook Express opens an SMTP connection to the local mail server running sendmail. The message is transmitted to the sendmail server using the SMTP protocol.    4. sendmail queries a DNS server for the MX record of the destination domain, i.e., example.org. The DNS server returns a hostname, e.g., mail.example.org.sendmail queries a DNS server for the A record of mail.example.org, i.e., the IP address. The DNS server returns an IP address of 127.118.10.3.    5. sendmail opens an SMTP connection to the remote mail server providing e-mail service for example.org which is also running sendmail. The message is transmitted to the sendmail server using the SMTP protocol.    6. sendmail delivers Larry's message for Martha to the local delivery agent. It appends the message to Martha's mailbox. By default, the message is stored in:            /var/spool/mail/martha.            7. Martha has her computer dial into her ISP.    8. Martha chooses Check Mail in Eudora.    9. Eudora opens a POP3 (Post Office Protocol version 3, defined in RFC1725) connection with the POP3 (incoming mail) server. Eudora downloads Martha's new messages, including the message from Larry.    10. Martha reads Larry's message.
The MTA, which is responsible for queuing up messages and arranging for their distribution, is the workhorse component of electronic mail systems. The MTA “listens” for incoming e-mail messages on the SMTP port, which is generally port 25. When an e-mail message is detected, it handles the message according to configuration settings, that is, the settings chosen by the system administrator, in accordance with relevant standards such as Request For Comment documents (RFCs). Typically, the mail server or MTA must temporarily store incoming and outgoing messages in a queue, the “mail queue.” Actual queue size is highly dependent on one's system resources and daily volumes.
MTAs, such as the commercially-available Sendmail® MTA, perform three key mail transport functions:                Routes mail across the Internet to a gateway of a different network or “domain” (since many domains can and do exist in a single network)        Relays mail to another MTA (e.g., 12b) on a different subnet within the same network        Transfers mail from one host or server to another on the same network subnetTo perform these functions, it accepts messages from other MTAs or MUAs, parses addresses to identify recipients and domains, resolves aliases, fixes addressing problems, copies mail into a queue on its hard disk, tries to process long and hard-to-pass messages, and notifies the sender when a particular task cannot be successfully completed. The MTA does not store messages (apart from its queue) or help users access messages. It relies on other mail system components, such as message delivery agents, message stores and mail user agents (MUAs), to perform these tasks. These additional components can belong to any number of commercial or free products (e.g., POP3 or IMAP servers, Microsoft Exchange, IBM Lotus Notes, Netscape, cc:Mail servers, or the like). Because of its central role in the e-mail systems, however, the MTA often serves as the “glue” that makes everything appear to work together seamlessly.        
The overall process may be summarized as follows. E-mail is routed via SMTP servers, the so-called “Mail Transfer Agents” (MTA). Users write, send, and read e-mail via Mail User Agents (MUA). To send e-mail, an MUA connects to an MTA which receives the e-mail and routes it to another MTA. An intermediary MTA might forward the e-mail to yet another MTA until the e-mail reaches the destination system, where the e-mail is stored in a mailbox accessible by the recipient.
For further description of e-mail systems, see e.g., Sendmail® for NT User Guide, Part Number DOC-SMN-300-WNT-MAN-0999, available from Sendmail, Inc. of Emeryville, Calif., the disclosure of which is hereby incorporated by reference. Further description of the basic architecture and operation of e-mail systems (including TLS, as described in further detail below) is available in the technical and trade literature; see e.g., the following RFC (Request For Comments) documents:
RFC821Simple Mail Transfer Protocol (SMTP)RFC822Standard for the Format of ARPA Internet Text MessagesRFC974Mail Routing and the Domain SystemRFC1123Requirements for Internet Hosts -- Application and SupportRFC1725Post Office Protocol version 3 (POP3)RFC2033Local Mail Transfer Protocol (LMTP)RFC2060Internet Message Access Protocol (IMAP), Ver. 4, rev. 1RFC2246The TLS Protocol, version 1.0RFC2487SMTP Service Extension for Secure SMTP over TLScurrently available via the Internet (e.g., ftp://ftp.isi.edu/in-notes), the disclosures of which are hereby incorporated by reference. RFCs are numbered Internet informational documents and standards widely followed by commercial software and freeware in the Internet and UNIX communities. The RFCs are unusual in that they are floated by technical experts acting on their own initiative and reviewed by the Internet at large, rather than formally promulgated through an institution such as ANSI. For this reason, they remain known as RFCs even once they are adopted as standards.
In an e-mail system, the system must identify its users to ensure safe usage of the system. In a typical configuration, an MTA exists on a company's local area network and, from the location, sends mail to and receives mail from users, including of course users that are outside of the local area network. Some of those users, particularly “remote” employees, may be communicating with the MTA via the Internet.
Currently, basic SMTP (e.g., as described by RFC821) does not provide any privacy or authentication. The content of e-mail can be read (“sniffed”) by many people, including system administrators (“sys admins”) with root privileges, and hackers “sniffing” a connection. Further, current attempts to address this problem are incomplete. For instance, some authentication/encryption mechanisms are available which address the problem using end-user to end-user encryption, e.g., PGP and S/MIME. These require that the users have (compatible) encryption mechanisms and software and know how to install, use, and maintain it. Other implementations are available which secure MTA-to-MTA connections. These implementations are not standardized and hence require the same software for each MTA that wants encryption.
TLS (Transport Layer Security), which is based on X509 certificates (public key cryptography), is a generic layer to provide authentication and encryption for many applications. In basic operation, the client and the server can authenticate each other through use of a certificate, a signed public key. STARTTLS is standardized protocol defined in RFC2487, which is based on TLS as described in RFC2246. It allows for authentication of servers and clients in an SMTP session based on public key cryptography (currently X.509 certificates and several ciphers). For an introduction to X.509 certificates, see e.g., Tremblett, P., “X.509 Certificates,” Dr. Dobb's Journal, July 1999, pp. 42–51, the disclosure of which is hereby incorporated by reference. RFC2487 does not specify how to ensure that actual transmissions are really authenticated and encrypted. It leaves this up to the actual implementation to enforce a policy.
What is needed is an easy way to ensure that e-mail is sent/received securely to/from a remote system, including authenticating the remote system before transferring e-mails. The present invention fulfills this and other needs.